chore(deps): bump go to 1.26.3 in all go.mod files#27772
Conversation
Signed-off-by: reggie-k <regina.voloshin@codefresh.io>
❌ Preview Environment deleted from BunnyshellAvailable commands (reply to this comment):
|
reggie-k
changed the title
reggie-k
changed the title
reggie-k
changed the title
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #27772 +/- ##
==========================================
+ Coverage 63.96% 63.99% +0.03%
==========================================
Files 421 421
Lines 57774 57774
==========================================
+ Hits 36954 36973 +19
+ Misses 17339 17321 -18
+ Partials 3481 3480 -1 ☔ View full report in Codecov by Sentry. |
| // Do NOT bump this unless we use features that are only available on the new version. | ||
| // If you want to update the BUILD version, just update go versions in the release workflows. | ||
| go 1.26.1 | ||
| go 1.26.3 |
There was a problem hiding this comment.
Given the commit above, what is the motivation for bumping it in this case?
There was a problem hiding this comment.
Yes I was wondering also about this comment myself - not sure why it's there and why it's. problem to bump this version.....
There was a problem hiding this comment.
This is a problem for anyone consuming some of these as a library. Upgrading the go requirement leads to a cascade of upgrades in dependant components. Hence the appeal on bumping it only when there is a pragmatic motivation.
Full disclaimer: Me employer in one such party.
There was a problem hiding this comment.
I think this comment is more relevant for cherry-picking Go bumps into an existing minor release - because it may be problematic to people that use Argo CD library to experience a breaking change upon an Argo CD patch release.
I think is is justified upgrading this for a new Argo CD minor release, even if at this point in time we don;t use any new language version features - because when we'd need to do so, cherry-picking the change into an existing minor release will result in a much poorer user experience.
@crenshaw-dev WDYT?
There was a problem hiding this comment.
when we'd need to do so, cherry-picking the change into an existing minor release will result in a much poorer user experience
I'm not sure I follow... is the idea that we should have master require the latest possible go release so that when we cherry-pick changes, it's more likely that the old release branch is on a new enough version to support the cherry-picked changes?
I think that's kind of low benefit for the cost of library users having to constantly upgrade go versions. I don't see changes cherry-picked very often that use such new go features that the cherry pick fails.
There was a problem hiding this comment.
should we just leave this as 1.26 with no patch version?
There was a problem hiding this comment.
Ok, this may not work https://go.dev/doc/toolchain#version. That means if any of our dependencies declare a version > 1.26 (eg 1.26.0+) it will require us to update our go.mod.
There was a problem hiding this comment.
Yep, the requirements stack. Which is why we shouldn't bump to latest, it makes us a bad neighbor. I'd default to 1.x.0 any time we don't have a good reason to bump that last digit (which should be almost always, since go has really strong compatibility guarantees).
| @@ -1,6 +1,6 @@ | |||
| module github.com/argoproj/argo-cd/gitops-engine | |||
|
|
|||
| go 1.26.1 | |||
There was a problem hiding this comment.
can we just leave this as 1.26?
|
@rumstead @crenshaw-dev I see what you are both saying. |
5 participants
Checklist: